Codecov Report

❌ Patch coverage is 80.00000% with 30 lines in your changes missing coverage. Please review.
✅ Project coverage is 35.32%. Comparing base (c3f56b5) to head (18fe87f).

@@             Coverage Diff              @@
##             master    #2994      +/-   ##
============================================
- Coverage     36.10%   35.32%   -0.79%     
- Complexity      338      499     +161     
============================================
  Files           803      803              
  Lines         68291    68381      +90     
  Branches       8970     8992      +22     
============================================
- Hits          24656    24154     -502     
- Misses        40990    41604     +614     
+ Partials       2645     2623      -22     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Thanks for your patience. The hstore CI failure exposed an existing latent issue in hstore's range-index query path. For range-index scans with limit/paging, the upper layer assumed that backend scan results were globally ordered by the range-index key and that the returned page state could be reused as a HugeGraph range cursor. In hstore, multi-node/tablet scans can return entries in backend iterator order, and the page state is an internal storage cursor, so those assumptions may lead to unstable ordering or skipped results. This PR keeps the fix intentionally scoped: hstore range-index queries whose visible result depends on limit/offset/paging are sorted and sliced in the index layer, while unbounded scans still use the original streaming path to avoid disturbing count, joint-index, and cleanup paths. I think this is enough for the current PR, but the underlying hstore scan/page-state contract should be handled in a dedicated follow-up, ideally by defining whether range scans must be globally ordered and fixing the hstore iterator/page-state semantics at the storage-client layer.

Thanks. I fixed this by resetting scanQuery.offset(0L) before the full sorted range-index scan, so the fallback now reads the complete matched range first and lets the original query apply offset/limit only once after sorting. I also added range-offset coverage to VertexCoreTest#testQueryByDateProperty to guard the double-skip case. Local checks passed with git diff --check, hugegraph-core compile, and VertexCoreTest#testQueryByDateProperty under the rocksdb core-test profile.

I took another look at the latest head and I don't think this should be treated as a generic pd-store timeout.

Current head: 18fe87f3c9a4e1a455340944ab5c66f175ce7f65

Current PR state:

reviewDecision:   APPROVED
mergeable:        MERGEABLE
mergeStateStatus: UNSTABLE

HugeGraph-PD & Store & Hstore CI
├─ struct: SUCCESS
├─ pd:     SUCCESS  06:00:35 -> 06:09:30
├─ store:  SUCCESS  06:00:29 -> 06:14:10
└─ hstore: CANCELLED 06:00:35 -> 12:00:50
   └─ Run core test: 06:05:23 -> 12:00:48

Other visible red check:
└─ codecov/project: FAILURE

So the failing GitHub Actions job is specifically hstore in HugeGraph-PD & Store & Hstore CI. pd and store passed on this run.

Why I don't think this is just a slow runner:

Recent successful HStore runs

run 27693769986
└─ hstore total:     about 24m26s
   Run core test:   about 10m21s

run 27893737780
└─ hstore total:     about 24m41s
   Run core test:   about 10m50s

run 28014295081
└─ hstore total:     about 24m26s
   Run core test:   about 10m29s

PR #2994 latest run 27739968315
└─ hstore total:     about 6h, then cancelled
   Run core test:   about 5h55m, then cancelled

The job was not stuck in dependency download, compile, or startup. It entered Run core test and then ran until GitHub cancelled the job at the 6-hour boundary.

The most relevant log evidence I found is the last useful stack before cancellation:

VertexCoreTest.testQueryInPageWithoutCapacity
  -> IteratorUtils.count(...)
  -> PageEntryIterator.hasNext/fetch
  -> QueryList.fetchNext
  -> GraphIndexTransaction.doIndexQueryOnce
  -> HStore iterator / KvPageScanner close

There is also a Netty ByteBuf.release() leak report around that path, but I would treat that as a symptom exposed during iterator close/cleanup, not as the primary explanation for why the core test never finishes.

The suspicious overlap with this PR is high:

PR changes
├─ QueryList.java
│  └─ paged index result fetch now keeps input order
├─ GraphIndexTransaction.java
│  └─ index scan filtering / matched-index read path changed
├─ HstoreTable.java
│  └─ adds RangeIndexEntryIterator for range-index paging
└─ VertexCoreTest.java
   └─ affected paging/index test area

Failed runtime path
└─ hstore core test
   └─ VertexCoreTest.testQueryInPageWithoutCapacity
      └─ paged index query
         └─ QueryList / GraphIndexTransaction / HStore iterator

My current hypothesis is that the HStore range-index paging cursor/page-state is not advancing correctly for this path. PageEntryIterator depends on the page returned by the lower layer to move forward. If the HStore range-index iterator returns a page state that points back to the same range/entry, the outer paging loop can repeatedly fetch the same page/range and keep the core test running until the CI timeout.

Conceptually:

g.V().has("age", 30).has("~page", "").limit(-1)
        |
        v
GraphIndexTransaction.doIndexQueryOnce()
        |
        v
HStore range-index scan
        |
        v
RangeIndexEntryIterator.pageState()
        |
        v
PageEntryIterator.fetch()
        |
        +-- if page state does not move monotonically
            fetch repeats / iterator cleanup repeats / test never completes

Given that this PR directly changes the HStore/query paging area, I don't think a rerun alone is enough evidence unless the same HStore range-index paging path is proven stable. I would not merge this head as-is. Please fix or revert the HStore range-index paging part, or move that piece into a dedicated follow-up where the storage-client page-state contract can be handled explicitly.

At minimum, I think we need a targeted regression check around:

HStore + range/index query + paging + no capacity / large limit

The Codecov project failure is still visible too, but the hstore timeout is the more important blocker because it overlaps with the changed behavior rather than looking like an unrelated external check.